<template >
    <div>
        <el-breadcrumb separator="/">
            <el-breadcrumb-item>运营规范</el-breadcrumb-item>
            <el-breadcrumb-item>有赞云平台规范</el-breadcrumb-item>
            <el-breadcrumb-item>开发规范</el-breadcrumb-item>
        </el-breadcrumb>
        <div class="detial">
            <div class="detialtitle">
                <div class="title">
                    开发规范
                </div>
            </div>

            <div class="knowledge-panel">
                <div class="knowledge-panel">
                    <div class="markdown-body">
                        <p><strong>一. 总则</strong></p>
                        <p>1、为保证有赞云平台的规范、有序、安全运营,特制定本规范。</p>
                        <p>2、本规则适用于所有入驻有赞云的开发者。</p>
                        <p>3、作为有赞云平台的开发者,除了解和遵守《有赞云平台服务协议》、《有赞云应用市场上架协议》、《有赞云应用授权服务协议》等相关平台的协议和规则的约束外还需仔细阅读并遵守本《有赞云开发规范》。
                        </p>
                        <p><strong>二. 应用开发规范</strong></p>
                        <p>1、若开发者开发的应用为自用型应用的,则应用授权店铺账号必须与开发者注册的有赞账号相一致。</p>
                        <p>2、若开发者开发的应用为工具性应用的,则开发者通过有赞云获取的商家数据均应事先获得商家授权且该数据仅可展现或使用于该授权商家不得向任何第三方组织或个人共享。</p>
                        <p>3、开发者不得聚合数据,应用系统后台不得将多个账号主体下的店铺进行统一展示。</p>
                        <p>4、应用名称使用规则:</p>
                        <p>需要提交正式、完整带上自己的正式品牌名未重复的应用名称。 </p>
                        <p>在未得到有赞品牌授权的情况下请勿在品牌名中使用“有赞“字样。 </p>
                        <p>申请名称请勿出现“测试”、“test”等字样。</p>
                        <p>申请名称请勿出现法律不允许的敏感词。</p>
                        <p>申请名称申请通过后无法修改申请名称需慎重。</p>
                        <p><strong>三. 应用使用规范</strong></p>
                        <p>1、应用创建后如3个月内未发布成功或工具型应用3个月内未上架应用市场平台将删除应用并回收应用标签。</p>
                        <p>2、应用近60天内无API有效调用的平台将删除应用并回收应用标签。</p>
                        <p>3、应用的使用者必须为该应用的开发者不得将账号密码转借或转让给任何第三方使用否则平台将删除应用并回收应用标签。</p>
                        <p><strong>四.API使用规范</strong></p>
                        <p>1、若API近90天无有效调用的有赞云平台有权收回开发者的API调用权限。</p>
                        <p>2、有赞非常重视商家的隐私因此开发者在通过开放API获取商家数据前必须先获得商家授权同时开发者需要采取必要的措施保护商家的隐私安全严禁将数据泄露给任何第三方否则有赞云平台有权将收回开发者的API调用权限；
                        </p>
                        <p>3、开发者调用API的行为若侵犯有赞权利的有赞云平台有权收回开发者的API调用权限。</p>
                        <p>4、开发者调用有赞接口的日均请求成功率需高于90%。</p>
                        <p>5、严禁开发者在富文本插入时注入恶意代码否则有赞云平台有权收回开发者的API调用权限。</p>
                        <p><strong>五. 代码安全规范</strong></p>
                        <p>1、针对“反序列化命令执行”漏洞</p>
                        <p> ( 1 )定义 Java反序列化是指把字节序列恢复为Java对象的过程ObjectInputStream类的readObject()方法用于反序列化。</p>
                        <p> ( 2 )风险 暴露或间接暴露反序列化API导致用户可以操作传入数据攻击者可以精心构造反序列化对象并执行恶意代码。</p>
                        <p> ( 3 )代码规范 </p>
                        <p>1 )使用spring、struts2、fastjson、dubbo等开源框架时一定要保证为最新版本；</p>
                        <p>2 )业务中自行开发的涉及到序列化与反序列化时在ObjectInputStream 中resolveClass 里只是进行了class
                            是否能被load自定义ObjectInputStream, 重载resolveClass的方法对className 进行白名单校验 </p>
                        <p>public final class test extends ObjectInputStream{</p>
                        <p> ...</p>
                        <p> protected Class&lt;?&gt; resolveClass(ObjectStreamClass desc)</p>
                        <p>​ throws IOException, ClassNotFoundException{</p>
                        <p>​ if(!desc.getName().equals("className")){</p>
                        <p>​ throw new ClassNotFoundException(desc.getName()+" forbidden!");</p>
                        <p>​ }</p>
                        <p>​ returnsuper.resolveClass(desc);</p>
                        <p> }</p>
                        <p> ...</p>
                        <p>}</p>
                        <p>2、针对“SSRF”漏洞</p>
                        <p> ( 1 )定义 SSRF(Server-Side Request Forger)即服务器端请求伪造是一种由攻击者构造形成由服务端发起请求的一个安全漏洞。</p>
                        <p> ( 2 )风险 一般情况下SSRF攻击的目标是从外网无法访问的内部系统。 ( 正是因为它是由服务端发起的所以它能够请求到与它相连而与外网隔离的内部系统
                            )如果没有对目标地址做过滤与限制时就会出现SSRF。
                        </p>
                        <p> ( 3 )代码规范 尽量不要使用服务器端请求的方式获取相关内容如无法避免服务器端对前端传来的 URL 进行请求时需验证 URL 的可靠性根据白名单策略进行过滤。</p>
                        <p>例如 URL url = new URL(check(uri)); 定义check白名单校验功能</p>
                        <p>3、针对“XXE”漏洞</p>
                        <p> ( 1 )定义及风险 XXE全称为XML External Entity attack:当XML解析时由于引用不可信的外部实体造成命令执行漏洞。</p>
                        <p> ( 2 )代码规范 解析XML时禁止外部实体</p>
                        <p>DocumentBuilderFactory domfac = DocumentBuilderFactory.newInstance();</p>
                        <p>domfac.setExpandEntityReferences(false);</p>
                        <p>4、针对“跨站XSS”漏洞</p>
                        <p> ( 1 )定义及风险 攻击者利用应用程序的动态展示数据功能在html页面里嵌入恶意代码 (
                            ” )。当用户浏览该页之时这些嵌入在html中的恶意代码会被执行用户浏览器被攻击者控制从而达到攻击者的特殊目的。</p>
                        <p> ( 2 )代码规范 </p>
                        <p>1 )node语言</p>
                        <p>如果node采用了nunjucks 模版 ( 目前大部分业务都采用该模板 )那么node主文件的 nunjucksConfig配置中设置autoescape:
                            true或者不做任何设置nunjuck输出的所有数据都会进行XSS转义。</p>
                        <p>当输出内容为富文本的时候可以局部关闭nunjuck转义功能。</p>
                        <p>如果node功能没有采用nunjuck模版那么可以在render渲染view的环节进行数据递归遍历转义采用node开源模块xss-escape。</p>
                        <p>针对富文本采用代码清洗的思路即保留正常的html标签入 <a> <b> </b></a></p>
                        <p><a><b>等的代码格式针对攻击性的js代码进行格式转义具体实现方式为 在render渲染环节针对数据进行遍历递归转义。</b></a></p><a><b>
                                <p>2 )java语言</p>
                                <p>非富文本 采用escape转义</p>
                                <p>富文本 采用owasp antisamy</p>
                                <p>3 )在javascript内容中输出的“用户可控数据”需要做javascript escape转义”。</p>
                                <p>5、针对“flash”漏洞</p>
                                <p> ( 1 )定义及风险 利用flash服务端和客户端在安全配置和文件编码上的问题导致攻击者可以利用客户端的flash文件发起各种请求或者攻击客户端的页面。</p>
                                <p> ( 2 )代码规范 </p>
                                <p>1 )Crossdomain.xml的安全配置</p>
                                <p>如果没有flash应用去掉crossdomian.xml文件对有flash应用域的根目录下需要配置crossdomain.xml策略文件
                                    设置为只允许来自特定域的请。不允许添加
                                    <site-control permitted-cross-domain-policies="by-content-type">
                                        这样会导致客户端可能自己加载自定义策略文件</site-control>
                                </p>
                                <p>2 )客户端嵌入flash文件的安全配置 </p>
                                <p>A.禁止设置flash的allowscriptaccess为always必须设置为never如果设置为SameDomain需要客户可以上传的flash文件要在单独的一个域下
                                </p>
                                <p>B.设置allowNetworking选项为none</p>
                                <p>C.设置allowfullscreen选项为false</p>
                                <p>6、针对“跨站请求伪造CSRF”漏洞</p>
                                <p> ( 1 )定义及风险 攻击者在用户浏览网页时利用页面元素 ( 例如img的src )强迫受害者的浏览器向Web应用程序发送一个改变用户信息的请求。</p>
                                <p> ( 2 )代码规范 </p>
                                <p>1 )用户登陆时设置一个CSRF的随机TOKEN同时种植在server的session中。</p>
                                <p>2 )生成表单的同时推送TOKEN值。</p>
                                <p>3 )表单提交判断token是否一致如果不一致或没有这个值判断为CSRF攻击并记录日志 如一致就放行并重新生成下一个新的token。</p>
                                <p>4 )重要操作增加二次图片验证码或滑动验证码等。</p>
                                <p>5 )致命操作使用二次密码验证或人脸识别等。</p>
                                <p>7、针对“URL跳转”漏洞</p>
                                <p> ( 1 )定义及风险 Web应用程序接收到用户提交的URL参数后没有对参数做“可信任URL”的验证就向用户浏览器返回跳转到该URL的指令。</p>
                                <p> ( 2 )代码规范 建议采取下列两种方案的其中之一进行开发 方案一 </p>
                                <p>1 )当用户访问需要生成跳转URL的页面时首先生成随机token并放入cookie。</p>
                            </b></a><b>
                            <p><a>2 )在显示连接的页面上生成URL在URL参数中加入token ( </a><a target="_blank"
                                    href="http://china.youzan.com/member/sigin.htm?done=http://www.youzan.com&amp;token=5743892783432432%EF%BC%89">http://china.youzan.com/member/sigin.htm?done=http://www.youzan.com&amp;token=5743892783432432
                                    )</a>
                            </p>
                            <p>3 )应用程序在跳转前判断token是否和cookie中的token一致如果不一致就判定为URL跳转攻击并记录日志</p>
                            <p>4 )如果在javascript中做页面跳转需要判断域名白名单后才能跳转。</p>
                            <p>方案二 </p>
                            <p>如果应用只有跳转到Youzan网站的需求可以设置白名单判断目的地址是否在白名单列表中如果不在列表中就判定为URL跳转攻击并记录日志。不允许配置Youzan以外网站到白名单列表中。
                            </p>
                            <p>8、针对“SQL注入”漏洞</p>
                            <p> ( 1 )定义及风险 当应用程序将用户输入的内容拼接到SQL语句中一起提交给数据库执行时就会产生SQL注入威胁。</p>
                            <p> ( 2 )代码规范 </p>
                            <p>1 )使用预处理执行SQL语句</p>
                            <p>2 )如果使用的是mybatis那么所有的变量必须使用#符号；如果特殊应用必须使用$的情况必须确保变量完全来源于系统内部或代码定义好的固定常量</p>
                            <p>9、针对“代码注入”漏洞</p>
                            <p> ( 1 )定义及风险
                                web应用代码中允许接收用户输入一段代码之后在web应用服务器上执行这段代码并返回给用户。由于用户可以自定义输入一段代码在服务器上执行所以恶意用户可以写一个远程控制木马直接获取服务器控制权限所有服务器上的资源都会被恶意用户获取和修改甚至可以直接控制数据库。
                            </p>
                            <p> ( 2 )代码规范 执行代码的参数或文件名禁止和用户输入相关只能由开发人员定义代码内容用户只能提交“1、2、3”参数代表相应代码。</p>
                            <p>10、针对“XML注入”漏洞</p>
                            <p> ( 1 )定义及风险
                                XML是存储数据的地方如果在查询或修改时如果没有做转义直接输入或输出数据都将导致XML注入漏洞。攻击者可以修改XML数据格式增加新的XML节点对数据处理流程产生影响。
                            </p>
                            <p> ( 2 )代码规范 在XML保存和展示前对数据部分单独做xml escape。</p>
                            <p>11、针对“系统命令注入”漏洞</p>
                            <p> ( 1 )定义及风险 系统命令执行攻击是指代码中有一段执行系统命令的代码但是系统命令需要接收用户输入恶意攻击者可以通过这个功能直接控制服务器。</p>
                            <p> ( 2 )代码规范 所有需要执行的系统命令必须是开发人员定义好的不允许接收用户传来的参数加入到系统命令中去。</p>
                            <p>12、针对“任意文件上传”漏洞</p>
                            <p> ( 1 )定义及风险
                                Web应用程序在处理用户上传的文件时没有判断文件的扩展名是否在允许的范围内就把文件保存在服务器上导致恶意用户可以上传任意文件甚至上传脚本木马到web服务器上直接控制web服务器。
                            </p>
                            <p> ( 2 )代码规范 </p>
                            <p>1 )检查上传文件扩展名白名单不属于白名单内不允许上传。</p>
                            <p>2 )上传文件的目录必须是http请求无法直接访问到的。如果需要访问的必须上传到其他 ( 和web服务器不同的 )域名下并设置该目录为不解析jsp等脚本语言的目录。</p>
                            <p>3 )上传文件要保存的文件名和目录名由系统根据时间生成不允许用户自定义。</p>
                            <p>4 )图片上传要通过处理 ( 缩略图、水印等 )无异常后才能保存到服务器。</p>
                            <p>13、针对“任意文件下载”漏洞</p>
                            <p> ( 1 )定义及风险
                                处理用户请求下载文件时允许用户提交任意文件路径并把服务器上对应的文件直接发送给用户这将造成任意文件下载威胁。如果让用户提交文件目录地址就把目录下的文件列表发给用户会造成目录遍历安全威胁。
                            </p>
                            <p> ( 2 )代码规范 </p>
                            <p>1 )要下载的文件地址保存至数据库中。</p>
                            <p>2 )文件路径保存至数据库让用户提交文件对应ID下载文件。</p>
                            <p>3 )下载文件之前做权限判断。</p>
                            <p>4 )文件放在web无法直接访问的目录下。</p>
                            <p>5 )不允许提供目录遍历服务。</p>
                            <p>14、针对“垂直权限安全”漏洞</p>
                            <p> ( 1 )定义及风险 由于应用程序没有做鉴权或鉴权做的比较粗导致的恶意用户可以通过穷举遍历管理页面的URL就可以访问或控制其他角色拥有的数据或管理功能达到权限提升目的。
                            </p>
                            <p> ( 2 )代码规范 采用细粒度鉴权策略判断当前用户是否拥有功能的权限如果没有权限就判定为“权限提升”攻击。</p>
                            <p>15、针对“水平权限安全”漏洞</p>
                            <p> ( 1 )定义及风险 应用程序根据用户提交的ID ( 如订单id、userid、余额id等
                                )在没有校验身份的情况下直接返回用户信息从而会造成攻击者越权遍历所有其他用户信息的问题。
                            </p>
                            <p> ( 2 )代码规范 涉及到用户数据的操作应进行严格的身份校验可以从服务端登录态cookie或session信息中取值校验禁止通过用户提交的ID信息直接进行数据操作。</p>
                            <p>16、针对“Cookie http only”漏洞</p>
                            <p> ( 1 )定义及风险 Cookie http only是设置COOKIE时可以设置的一个属性如果COOKIE没有设置这个属性该COOKIE值可以被页面脚本读取。</p>
                            <p> ( 2 )代码规范 </p>
                            <p>设置cookie时加入属性即可具体如下 </p>
                            <p>response.setHeader("SET-COOKIE", "user=" + request.getParameter("cookie") + ";
                                HttpOnly");</p>
                            <p>17、针对“Cookie Secure”漏洞</p>
                            <p> ( 1 )定义及风险 Cookie Secure是设置COOKIE时可以设置的一个属性设置了这个属性后只有在https访问时浏览器才会发送该COOKIE。</p>
                            <p> ( 2 )代码规范 </p>
                            <p>在设置认证COOKIE时加入Secure具体如下 </p>
                            <p>response.setHeader("SET-COOKIE", "user=" + request.getParameter("cookie") + "; HttpOnly ;
                                Secure ");</p>
                            <p>18、针对“Session 有效期”漏洞</p>
                            <p> ( 1 )定义及风险 由于Session没有在web应用中设置强制超时时间攻击者一旦曾经获取过用户的Session就可以一直使用。</p>
                            <p> ( 2 )代码规范
                                在设置认证cookie中加入两个时间一个是“即使一直在活动也要失效”的时间一个是“长时间不活动的失效时间”。并在web应用中首先判断两个时间是否已超时再执行其他操作。
                            </p>
                            <p>19、针对“伪随机性”漏洞</p>
                            <p> ( 1 )定义及风险 如果使用Random()生成的图片验证码那么根据前两个值就可以计算出来后面的所有随机值。</p>
                            <p> ( 2 )代码规范 </p>
                            <p>1 )在java中推荐采用secureRandom()函数代替伪随机的Random()函数。该算法提供了强随机的种子算法(SHA1PRNG)；</p>
                            <p>2 )使用随机算法时尽量将随机数种子复杂化例如在以ServerTime作为随机种子时在其后面加一个固定的“offside”整数值这样可以有效避免被猜到随机种子的来源。
                            </p>
                            <p>20、针对“弱加密强度”漏洞</p>
                            <p> ( 1 )定义及风险 项目中设计到敏感信息的数据采用程序员自己编写的“简单算法”加密一旦被人获取足够的“样本”将有可能被反向推测出解密算法从而泄露重要信息。</p>
                            <p> ( 2 )代码规范 </p>
                            <p>1 )不要将编码(如Base64)和密码算法混为一谈前者不是密码算法。</p>
                            <p>2 )不要使用低强度的密码算法如DES、RC2等必须采用符合业内安全强度标准的密码算法</p>
                            <p>21、针对“错误处理”漏洞</p>
                            <p> ( 1 )定义及风险 在web应用程序出错时会返回一些程序异常信息从而暴露很多对攻击者有用的信息攻击者可以利用这些错误信息制定下一步攻击方案。</p>
                            <p> ( 2 )代码规范 配置错误页面让所有的错误都只显示友好信息不显示任何与实际错误相关的信息。</p>
                            <p>22、针对“认证”漏洞</p>
                            <p> ( 1 )定义及风险 如果没有严格的登陆认证策略极有可能遭到频繁的暴力破解、字典攻击。</p>
                            <p> ( 2 )代码规范 </p>
                            <p>1 )所有系统必须启用账号失败锁定策略 ( 如 3分钟失败10次 锁定10分钟 )；</p>
                            <p>2 )用户账号或密码错误时返回的信息必须一致 ( 如 您的账号或密码错误 )；</p>
                            <p>3 )所有具备登陆功能的系统必须同时具备注销或退出功能。</p>
                            <p>23、针对“验证码”漏洞</p>
                            <p> ( 1 )定义及风险 登陆、注册、短信验证、邮件验证等api往往会成为攻击者撞库、轰炸的目标。</p>
                            <p> ( 2 )代码规范 </p>
                            <p>1 )登陆、注册、短信发送、邮件发送等环节必须加入图片验证码；</p>
                            <p>2 )验证码必须设置有效期和有效次数 ( 一般为一次性 )；</p>
                            <p>3 )使用短信/邮件验证时必须限制同一ID或接收者的验证码发送频率。</p>
                            <p>24、针对“明文传输”漏洞</p>
                            <p> ( 1 )定义及风险 攻击者通过嗅探的方式很容易获取http中的所有数据。</p>
                            <p> ( 2 )代码规范 </p>
                            <p>1 )禁止使用http get的方式提交不安全算法处理过的账号密码；</p>
                            <p>2 )禁止在http明文协议中传输任何敏感数据；</p>
                            <p>3 )requst中字段尽量不要使用username、passpwrd等常见单词。</p>
                            <p><strong>六. 规范的发布与更新</strong></p>
                            <p>1、有赞云平台会在必要时调整本规范且无需另行通知开发者新的规范一旦公开即有效替代原来的规范并对有赞、有赞云、开发者产生约束力。</p>
                            <p>2、本规范是开发者已经签署的《有赞云平台服务协议》等相关协议的一部分与其有同等效力自该规范发布之日起对有赞、有赞云、开发者产生约束力。</p>
                            <p><strong>七.数据存储和使用规范</strong></p>
                            <p>1、数据库命名规范</p>
                            <p> ( 1 )所有数据库对象名称必须使用小写字母并用下划线分割</p>
                            <p> ( 2 )所有数据库对象名称禁止使用mysql保留关键字(如果表名中包含关键字查询时需要将其用单引号括起来)</p>
                            <p> ( 3 )数据库对象的命名要能做到见名识意并且最后不要超过32个字符</p>
                            <p> ( 4 )临时库表必须以tmp<em>为前缀并以日期为后缀备份表必须以bak</em>为前缀并以日期(时间戳)为后缀</p>
                            <p> ( 5 )所有存储相同数据的列名和列类型必须一致(一般作为关联列如果查询时关联列类型不一致会自动进行数据类型隐式转换会造成列上的索引失效导致查询效率降低)</p>
                            <p>2、数据库基本设计规范</p>
                            <p> ( 1 )所有表必须使用Innodb存储引擎</p>
                            <p>没有特殊要求(即Innodb无法满足的功能如
                                列存储存储空间数据等)的情况下所有表必须使用Innodb存储引擎(mysql5.5之前默认使用Myisam5.6以后默认的为Innodb)Innodb
                                支持事务支持行级锁更好的恢复性高并发下性能更好</p>
                            <p> ( 2 )数据库和表的字符集统一使用UTF8</p>
                            <p>兼容性更好统一字符集可以避免由于字符集转换产生的乱码不同的字符集进行比较前需要进行转换会造成索引失效</p>
                            <p> ( 3 )所有表和字段都需要添加注释</p>
                            <p>使用comment从句添加表和列的备注 从一开始就进行数据字典的维护</p>
                            <p> ( 4 )尽量控制单表数据量的大小建议控制在500万以内</p>
                            <p>500万并不是MySQL数据库的限制过大会造成修改表结构备份恢复都会有很大的问题</p>
                            <p>可以用历史数据归档(应用于日志数据)分库分表(应用于业务数据)等手段来控制数据量大小</p>
                            <p> ( 5 )谨慎使用MySQL分区表</p>
                            <p>分区表在物理上表现为多个文件在逻辑上表现为一个表 谨慎选择分区键跨分区查询效率可能更低 建议采用物理分表的方式管理大数据</p>
                            <p> ( 6 )尽量做到冷热数据分离减小表的宽度</p>
                            <p>MySQL限制每个表最多存储4096列并且每一行数据的大小不能超过65535字节
                                减少磁盘IO,保证热数据的内存缓存命中率(表越宽把表装载进内存缓冲池时所占用的内存也就越大,也会消耗更多的IO) 更有效的利用缓存避免读入无用的冷数据
                                经常一起使用的列放到一个表中(避免更多的关联操作)</p>
                            <p> ( 7 )禁止在表中建立预留字段</p>
                            <p>预留字段的命名很难做到见名识义 预留字段无法确认存储的数据类型所以无法选择合适的类型 对预留字段类型的修改会对表进行锁定</p>
                            <p> ( 8 )禁止在数据库中存储图片文件等大的二进制数据</p>
                            <p>通常文件很大会短时间内造成数据量快速增长数据库进行数据库读取时通常会进行大量的随机IO操作文件很大时IO操作很耗时 通常存储于文件服务器数据库只存储文件地址信息
                            </p>
                            <p> ( 9 )禁止在线上做数据库压力测试</p>
                            <p> ( 10 )禁止从开发环境测试环境直接连接生成环境数据库</p>
                            <p>3、数据库字段和索引设计规范</p>
                            <p> ( 1 )优先选择符合存储需要的最小的数据类型</p>
                            <p> ( 2 )避免使用TEXT、BLOB数据类型最常见的TEXT类型可以存储64k的数据</p>
                            <p> ( 3 )避免使用ENUM类型</p>
                            <p> ( 4 )尽可能把所有列定义为NOT NULL</p>
                            <p> ( 5 )使用TIMESTAMP(4个字节)或DATETIME类型(8个字节)存储时间</p>
                            <p> ( 6 )同财务相关的金额类数据必须使用decimal类</p>
                            <p> ( 7 )限制每张表上的索引数量建议单张表索引不超过5个</p>
                            <p> ( 8 )禁止给表中的每一列都建立单独的索引</p>
                            <p> ( 9 )每个Innodb表必须有个主键</p>
                            <p>4、数据安全</p>
                            <p> ( 1 )明文风险 明文存储用户敏感数据一旦发生内部泄漏会对公司产生致命的威胁可能造成刑事风险。</p>
                            <p> ( 2 )加密存储 禁止数据库、日志文件中存储个人信息和敏感数据 ( 如 用户姓名、电话、身份证、银行卡、邮箱地址、密码等 )禁止使用不安全算法存储这些数据。</p>
                            <p> ( 3 )保密要求 数据库管理员、数据库安全员、数据库审计员应签署保密协议。</p>
                            <p> ( 4 )访问要求 正常的业务操作和数据维护只能通过应用系统访问数据库。</p>
                        </b>
                    </div>
                </div>
            </div>

        </div>
    </div>
</template >

<script >
export default {

}
</script >

<style lang="less" scoped >
.mian {

    margin-bottom: 24px;
}

p {
    font-size: 14px;
    margin-bottom: 16px;
    margin-top: 0;
}

.detial {

    box-sizing: border-box;
    text-align: left;

    .detialtitle {

        display: flex;
        align-items: flex-end;
        justify-content: space-between;
        margin-top: 24px;
        margin-bottom: 16px;
        padding-bottom: 16px;
        border-bottom: 1px solid #ebedf0;

        .title {
            color: #323233;
            font-weight: 700;
            font-size: 20px;
            line-height: 30px;
            text-align: left;
        }

        .markdown-body {
            min-height: 400px;
            -ms-text-size-adjust: 100%;
            -webkit-text-size-adjust: 100%;
            margin: 0;
            color: #24292f;
            background-color: #fff;
            font-family: -apple-system, BlinkMacSystemFont, Segoe UI, Helvetica, Arial, sans-serif, Apple Color Emoji, Segoe UI Emoji;
            font-size: 16px;
            line-height: 1.5;
            word-wrap: break-word;


        }

        .markdown-body:after {
            display: table;
            clear: both;
            content: "";
        }

        .markdown-body:before {
            display: table;
            content: "";
        }

    }
}
</style >